Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

@haseebmalik18 can you look at failures?

Yes, I've taken a look I understand what the issue is I will have it in a day or two

@vatsrahul1001 Just made the fixes. Should be good now.

@haseebmalik18 can you look at review comments?

@vatsrahul1001 The E2E test for audit log pagination currently creates 4 events via 3 DAG triggers, but the UI config sets page_size: 15, so pagination won't trigger. To properly test pagination, we'd need 16+ events, which would require ~14+ DAG triggers which would be quite slow. What would you say is the recommended approach for generating event logs to generate pagination direct DB inserts, lower page_size config for tests, or another method?

@haseebmalik18 Thanks for working on this! Few things to address:

1. Boolean return methods - Methods like isAuditLogTableVisible() that catch errors and return false make debugging hard. Use Playwright assertions directly instead.

2. Data validation - The current check just verifies "something exists". Better to verify actual content - event types (dag_triggered, created, etc.) and date formats.

3. Sorting - Currently only checks that order changed, not that it's sorted correctly. Verify the actual sort direction.

4. DagsPage changes - Why was waitForDagList() removed? Seems unrelated to audit log tests. Please revert or explain.

5. Pagination - You can use the limit URL param to force smaller page size:

   /dags/{dagId}/events?offset=0&limit=3

   This way 4 events will trigger pagination (3 on page 1, 1 on page 2). Just update navigateToAuditLog to accept an optional limit parameter.

Let me know if you have questions!

@vatsrahul1001 Made all the changes

@haseebmalik18 I see chrome test are flaky. It passed on retry. Can you look into this?

@vatsrahul1001 Made the fix

@vatsrahul1001 The chrome test is passing now. That failed test looks like it's from a different test suite, is that unrelated to our UI testing?

@vatsrahul1001 The chrome test is passing now. That failed test looks like it's from a different test suite, is that unrelated to our UI testing?

@haseebmalik18 PR looking in good shape. Nice work!. A few minor comments for the test case rename.

I have re-run tests

@vatsrahul1001 Made the test case rename changes. Also I was wondering since I made a bunch of commits will it auto squash into one commit?

@vatsrahul1001 Made the changes

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.